Include sub (user ID), email, roles, iat, exp, and jti for revocation. Keep payloads small — they travel with every request. Never include passwords, sensitive PII, credit card numbers, or SSNs. JWTs are Base64-encoded and readable by anyone who holds the token without needing the secret.
JWTs are Base64url-encoded — not encrypted by default; anyone with the token can read the payload.
Include only what guards and services need to avoid a database lookup on every request.
jti (JWT ID) enables per-token revocation via a Redis blacklist without invalidating all tokens.
Avoid embedding frequently-changing data like permissions — stale data in long-lived tokens causes bugs.
Use JWE (JSON Web Encryption) if the payload must contain sensitive data and cannot be avoided.
In a NestJS controller you need to issue a JWT after a user logs in. What fields would you put in the token payload, and what would you avoid putting there?
If you accidentally include the user's password hash in the JWT payload, what could happen and how would you detect it?
How would you add an expiration claim to the payload using the NestJS JwtService?
We noticed that after deploying a new version, some users are getting 'Invalid token' errors. The payload includes a large user profile object. Walk me through how you would debug this and what you might change about the payload.
Your team wants to include role‑based permissions in the JWT to avoid DB lookups on each request. What are the trade‑offs of putting detailed permission lists in the payload versus a simple role claim?
During a security audit, you’re asked to ensure no sensitive PII is in the JWT. How would you audit existing payloads and enforce constraints in a NestJS microservice?
Design a strategy for handling token revocation in a system that uses stateless JWTs. How does the choice of payload content affect your revocation approach, and what patterns would you use in NestJS?
At high scale, you see JWTs growing to several kilobytes because the payload contains user settings. What performance and network implications does this have, and how would you redesign the payload while keeping NestJS authentication seamless?
Explain how you would implement a rotating secret key strategy for JWTs and what payload considerations (e.g., alg, kid) you need to support in NestJS.
Our organization is moving from a monolith to a set of independent services, each using NestJS and JWT for auth. How would you define a shared payload schema that balances security, versioning, and backward compatibility across teams?
We have legacy services that embed custom claims in JWTs that are now considered insecure. Describe a migration plan to refactor payload contents, update all NestJS services, and avoid breaking existing clients.
Considering cross‑team compliance requirements like GDPR, how would you design a system to ensure that no prohibited data ever ends up in JWT payloads, and how would you enforce this at compile‑time or CI in a large NestJS codebase?